![]() |
|||
![]()
|
![]() |
![]() Click Here! |
![]() |
Father-Son Rotation Schemes An example would be a small manufacturing concern whose network has 120 nodes, two servers, and a total of 2G bytes on the server disks. The network is running three shifts, five days a week, and there is only one hour each night during the week to perform routine backup. The ability to restore data is crucial, but only four hours is available in which to do it. Three to four weeks of data history is sufficient. In this case, the eight-tape rotation schedule shown in Exhibit 7-4-1 might be chosen.
The eight-tape schedule provides for one full backup on Fridays, augmented with four incremental backups Monday through Thursday. The Friday tape is on a separate sub-schedule of four tapes. During week one, tapes one through five are used. During week two, tapes one through four are followed by tape six, and so on until tape eight is used. Then the cycle repeats. This is ideal because the daily incrementals can be done during the 60-minute window each night (which is enough time to back up at least 300M bytes of changed data) and for the Friday backup there is plenty of time before the next shift starts. The only penalty this arrangement has is restoration time. In a worst-case scenario (i.e., restoring an entire volume), it would be necessary to load the last full backup tape, followed by every subsequent incremental tape, to ensure that the latest version of every file is restored. If more time is available at night for doing backups and less for restore, differential backups would be done in place of the incrementals. If a longer file history is required, more tapes would be included in the weekly, father tape rotation. Many other father-son schemes can be constructed. Performing two full backups a week on Tuesday and Friday, with incrementals on Monday, Wednesday, and Thursday will increase confidence and restore times but will take more time at night twice a week. Keeping three weeks of history will now require 11 tapes. Performing a full backup every night is the safest method of securing data and requires the least restore time. However, it requires the most time each night and will cost as much in tapes as a father-son scheme that has one father tape being made each week, that covers the same history period. Grandfather-Father-Son Grandfather-father-son schemes increase the history period, but leave more holes in it. Suppose the company decides that it must keep three to four months of data history. One method would be to simply increase to 16 the number of tapes used for full weekly backups. A slightly different rotation accomplishes the same coverage with six tapes, but the gaps in coverage increase as time moves on. The grandfather-father-son scheme uses incremental or differential backups each weekday night. Four tapes are rotated for these. Each weekend for three weeks (Friday 1, Friday 2, Friday 3) a full backup is done and once every four weeks a monthly backup is performed. A new monthly tape is used each month (i.e., each four week period) for three months (Monthly 1, Monthly 2, Monthly 3) before the rotation starts over (as shown in Exhibit 7-4-2). Data can be recovered from any day in the most recent week, any of the previous four weeks, plus data that is up to 12 weeks old in four week increments. To increase the number of months in the history more monthly tapes can be added.
Tower of Hanoi Tape Rotation If economy and a long history period are required, the Tower of Hanoi algorithm can be used (at the expense of increasing the complexity of backup operations) for father weekly full backups. The usual four tape son rotation of weekday incremental or differential backups is still used, as in the schemes discussed earlier. This scheme (named for a childs toy) uses weekend tapes at exponentially growing intervals and gets up to 2n - 1 weeks of coverage for n tapes. Five tapes therefore, can give up to 16 weeks coverage, as shown in Exhibit 7-4-3.
The rotation is then repeated. Just before Tape 5 is reused at week 32, its data is 16 weeks old, Tape 4s data is 8 weeks old, Tape 3 is 4 weeks old, Tape 2 is 2 weeks and Tape 1 is 1 week old. This is approximately the same coverage as grandfather-father-son with one less tape. Simplicity is probably worth the cost of an extra tape. A weakness of this scheme is the high use and hence potential failure of tape 1. Exhibit 7-4-4 illustrates the length of file history, the gaps in the file history coverage, and the number of tapes required for these different tape rotation schemes.
MANAGING STORAGE Monitoring Volume Use Storage requirements are likely to change over time. An administrator should monitor the data storage devices to determine when additional storage is needed. Usually, filing a volume to 70% to 80% of its capacity is a comfortable range. This depends on the size of the volume and the type of data stored on it. More free volume space should be maintained if the data is subject to temporary files causing rapid growth spurts, and less is required if the data is largely stable. Deciding when a volume is full means understanding the mix of programs that will run and their storage profiles. For example, the month end financial program may use many intermediate temporary files and overflow the disk once a month unless this is anticipated. Understanding the storage profile of disks is key. Performance is also influenced by a lack of available disk space. Full disks are usually fragmentedthat is, the space allocated is scattered across the disk rather than localized. The last files written are likely to be the ones most often accessed, and these are the ones that are most heavily fragmented. Disk fragmentation causes head movement even when clever caching algorithms are used, resulting in a decrease in performance. Keeping sufficient disk space open allows the system to maintain performance. Adding disks is not necessarily the answer to dwindling free space. Archiving dormant files (i.e., files that have not been accessed in some predetermined period of time) will probably free up sufficient disk space.
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |